Software development production management system, computer program, and recording medium

ABSTRACT

Provided is a software development production management system, which is enhanced in reliability by reducing a difference between an evaluation of an actual development and a formed plan. A management database ( 3 ) holds both development process component data necessary to model a development process of software and estimation parameter data used to estimate a development plan of the software. A software development production management device ( 1 ) defines a software development process to be managed by consulting the development process component data held in the management database ( 3 ), and uses the estimation parameter data to create a software development plan from the defined software development process. Further, the software development production management device ( 1 ) compares and evaluates, upon completion of the software development, an actually performed development process and the previously created software development plan, and makes a correction to the estimation parameter data as needed to feed details of the actually conducted software development back to the next development plan.

TECHNICAL FIELD

The present invention relates to a production management system which isused in developing a software product for software product productionmanagement (forming a development plan, measuring actual performance andevaluating plan achievement level during development, controllingsoftware product development activities based on evaluation, andaccumulating the organization's actual performance in software productdevelopment and grasping the rate of improvement in software productdevelopment efficiency upon completion of the development).

BACKGROUND OF THE INVENTION

A common way of modeling the process of developing a software product isto use the so-called waterfall model, the premise of which is that worksin a downstream process cannot be started until after the specificationof its upstream process is established.

Basically, a project plan (defines the creation period of a productcreated in a development process and a person in charge of the creation)which serves as the basis of production management in softwaredevelopment is created according to the man-hour of work in therespective processes. Examples of how the man-hour is estimated includethe function point method (FP method) which determines the scale ofsoftware from the software's functions and the COCOMO model which paysattention to the count of source code lines to determine the scale ofsoftware (see Non-patent Document 1, for example).

A technique for improving the precision of a project plan has beenproposed in which products created in the process of developing softwareare established, work procedures for creating the products and inputproducts necessary for the work are held, and the man-hour of eachproduct is estimated from its input product (see Patent Document 1).

[Non-Patent Document 1]

“Software Cost Estimation”, Joho Shari (the magazine of InformationProcessing Society of Japan), Vol. 33, No. 08 (1992)

[Patent Document 1]

JP 08-202773 A

The productivity of software development is measured generally by thescale of the software product and the time required for the development.Conventionally employed measures of the software product scale are thecount of source code lines upon completion of the development, functionpoints, the document amount of the software product, and the like. Asthe time required for the development, the total count of people and thetime reported by individual engineers but yet to be validated arecollected and employed. In measuring the productivity of softwareproduct development where multiple engineers participate, the time putforth by one engineer and the time put forth by another are treateduniformly as having the same value, despite the fact that eachindividual engineer has different abilities. The actual productivityperformance thus contains mixed abilities of individual engineers, whichimpairs the validity of applying a statistical value derived from pastactual performance values to a plan value of the developmentproductivity by way of feedback.

Patent Document 1, in particular, does not mention the developmentproductivity and the premise of the technique disclosed therein is thatan accurate estimation value is input for the man-hour required for thedevelopment. Furthermore, the validity of comparing the productdevelopment productivity between different software projects is notheld. It is therefore impossible to compare plan values of thedevelopment productivity required for software product development witheach other for evaluation of relative merits and to measure the degreeof improvement from a comparison with past actual performance values.

Moreover, in actual development, a specification cannot be establishedfully in an upstream process and starting on work in a downstreamprocess before the specification is established is accordinglyunavoidable. In other words, a change in specification is the norm inthe process of software development, and the specification change causesthe disposal, replacement, and addition of a source code or a product ofsoftware development. As a matter of fact, a product developed halfwayis often discarded in the process of software product development.

It is usually the scale of a finished software product that is measuredas the software product scale, and the measured software product doesnot contain the scale of a product that has been created during thedevelopment but discarded as a result of a specification change(hereinafter referred to as “change net discarded scale”). Since thechange net discarded scale is not incorporated in the softwareproduction scale despite the fact that the work put forth before thedisposal due to the specification change is valid, the actualproductivity performance is varied depending on how many times thespecification has been changed. In other word, the productivity which isone of process capabilities of software development cannot be measuredaccurately unless the change net discarded scale is added to the scaleof the finished product.

In addition, although a change in specification occurs duringdevelopment, prior art does not take a specification change duringdevelopment into consideration, and needs to change the project planonce a specification change occurs. This is one of the factors thatlower the precision of the project's process plan.

An object of the present invention is therefore to provide a softwaredevelopment production management system capable of forming asappropriate a software development plan as possible and, if there is adifference between the assessment of actual development and the formedplan, enhancing the reliability progressively by feeding the differenceback to data based on which a plan is formed.

According to the present invention, there is provided a softwaredevelopment production management system including: a managementdatabase which holds development process component data necessary tomodel a development process of software, and estimation parameter dataused to estimate a development plan of the software; and a softwaredevelopment production management device which defines a softwaredevelopment process to be managed by consulting the development processcomponent data held in the management database, and uses the estimationparameter data to create a software development plan from the definedsoftware development process, in which the software developmentproduction management device has a processing means which, uponcompletion of the software development, compares and evaluates anactually performed development process and the created softwaredevelopment plan, and makes a correction to the estimation parameterdata based on results of the comparison and evaluation so that detailsof the actually conducted software development can be fed back to adevelopment plan for the next time software is developed.

Further, according to the present invention, in the software developmentproduction management system, the software development productionmanagement device includes: a standard plan integration module whichdefines the software development process to be managed based on thedevelopment process component data, and then creates a standard softwaredevelopment plan containing scales and man-hours of respective workoperations in the defined software development process; an executionplan creating module which assigns the work operations to workers takinginto consideration the scales and man-hours of the respective workoperations in the standard software development plan, and correctsdetails of the work operations assigned in accordance with abilities ofthe respective workers to create an adjusted software development plan;an actual performance information collecting module which, in developingsoftware in accordance with the adjusted software development plan,collects actual performance information containing actual man-hourperformance and actual scale performance, the actual man-hourperformance being a man-hour that is actually put in by the respectiveworkers, the actual scale performance being a scale of work that isactually done; a process completion monitoring module which, uponcompletion of the software development, evaluates a difference betweendetails of the actually conducted development and the softwaredevelopment plan created in the execution plan creating module in amanner that includes a cause of the difference and quality of thedeveloped software in the evaluation, and feeds results of theevaluation back to an adjustment made by the execution plan creatingmodule; and an individual productivity evaluating module which evaluatesinformation about productivities of the respective workers taking intoconsideration the actual man-hour performance and the actual scaleperformance, and feeds results of the evaluation back to an adjustmentmade by the execution plan creating module

Further, according to the present invention, in the software developmentproduction management system, the software development productionmanagement device includes an actual production performance evaluatingmodule which performs comparative evaluation between softwaredevelopment plan forming and work according to the formed plan onmultiple software development projects to take statistics, and feeds thestatistics back to the creation of the standard software developmentplan in the standard plan integration module

While keeping track of the past record of software development isbecoming be common in the current software industry, accumulating it asempirical values in preparation for the next development to be reused increation of a software development plan by way of feedback presents adifficulty in setting a measure of quantification, and therefore has notbeen realized.

Further, according to the present invention, in the software developmentproduction management system, the management database holds, as aproductivity empirical value, a labor cost per unit amount of a product,and records a unit labor cost of each employee, and the execution plancreating module calculates productivity of each employee by dividing aproduct of the productivity empirical value and an actual product amountby the unit labor cost of each employee.

Further, according to the present invention, in the software developmentproduction management system, the management database has givendevelopment productivity reference data which is a ratio of a givenworkload to given product amount, the given workload being a workload ina given software development environment, the given product amount beinga product amount in the given software development environment, and theexecution plan creating module uses a first comparison coefficient and asecond comparison coefficient as tailoring parameters, and calculatesdevelopment productivity reference data in software development forwhich a plan is to be formed by an expression “given developmentproductivity reference data×second comparison coefficient/firstcomparison coefficient”, the first comparison coefficient being a ratioof a product amount in an environment of the software development forwhich a plan is to be formed to the given product amount, the secondcomparison coefficient being a ratio of a workload in the environment ofthe software development for which a plan is to be formed to the givenworkload.

In the current software industry, there are no integrated measures and,although empirical values of the productivities of very similar softwaredevelopment projects are accumulated to be reused, reusing empiricalvalues in software development of different characteristics is notpracticed.

Further, according to the present invention, in the software developmentproduction management system, the management database holds aproductivity fluctuation rate which takes into account factorsinfluencing a software development productivity, and the execution plancreating module calculates a development productivity in the softwaredevelopment for which a plan is to be formed from the developmentproductivity reference data and the productivity fluctuation rate.

Further, according to the present invention, in the software developmentproduction management system, the execution plan creating module keepstrack of each specification change made to a software product in termsof a specification change time which is when the specification change isthought to occur, a change added scale which is an amount added due tothe specification change, and a change discarded scale which is anamount discarded due to the specification change, and the change addedscale is added to an initial scale and the change discarded scale issubtracted from the initial scale each time the specification changetime arrives to calculate an ultimately realized scale which is a scalethe software product will have upon completion, the initial scale beinga software product scale that is created in the standard planintegration module.

Further, according to the present invention, in the software developmentproduction management system, the management database holds a standardrate for each work operation, the standard rate being an expected valueof a labor cost in relation to a unit time of a group of standardworkers, and the execution plan creating module calculates for each workoperation a development labor cost required for the software developmentwith respect to work operations of the respective workers, and dividesthe development labor cost by the standard rate to calculate a work timeof the work in question.

Further, according to the present invention, in the software developmentproduction management system, the management database holds for eachworker an ability rank of each worker as an attribute, and holds foreach rank a skill coefficient, which is based on how long it takes for aworker of this rank to master a work operation, and, when a worker isassigned to a work operation, the execution plan creating modulecalculates a time required for the assigned worker to finish the workoperation from the rank of the assigned worker and the skill coefficientof this work operation.

Further, according to the present invention, in the software developmentproduction management system, the individual productivity evaluatingmodule updates the ranks of the respective workers based on actuallyconducted work operations.

Further, according to the present invention, in the software developmentproduction management system, the process completion monitoring modulecalculates a scale of actually developed software by adding a change netdiscarded scale to a final scale of the software, evaluates actual workbased on the calculated scale of the software, makes a result of theevaluation reflected on the estimation parameter data, and/or obtainsintermediate development productivity reference data from an actualdevelopment productivity and an actual productivity fluctuation rate,the change net discarded scale being a discarded amount of an alreadydeveloped part which is discarded due to a specification change in aprocess of software development, the actual development productivitybeing a development productivity in the actually conducted softwaredevelopment, the actual productivity fluctuation rate being set takinginto consideration a factor unique to this software development that hasactually influenced the actual development productivity, and the processcompletion monitoring module uses the first comparison coefficient andthe second comparison coefficient, which are set upon planning, toautomatically remove a correction made due to an environment of thissoftware development from the intermediate development productivityreference data, thereby obtaining more general development productivityreference data and enhancing accuracy of the given developmentproductivity reference data.

Also, according to the present invention, a computer program andrecording medium for causing a computer to operate as a softwaredevelopment production management system are obtained.

The computer program builds, when read and executed by a computer with astorage device, builds in the storage device a management database forholding development process component data necessary to model adevelopment process of software, and estimation parameter data used toestimate a development plan of the software, and causes the computer tooperate as a software development production management device, thesoftware development production management device defining a softwaredevelopment process to be managed by consulting the development processcomponent data held in the management database, and using the estimationparameter data to create a software development plan from the definedsoftware development process. The computer program forms in the computera processing means which, upon completion of the software development,compares and evaluates an actually performed development process and thecreated software development plan, and makes a correction to theestimation parameter data based on results of the comparison andevaluation so that the computer can feed details of the actuallyconducted software development back to a development plan for the nexttime software is developed. Further, the recording medium is acomputer-readable recording medium which records the computer programdescribed above.

According to the present invention, a development plan is formed basedon given information and the given information can be updated withinformation obtained through actual development. The precision of aformed plan is therefore enhanced by repeatedly performing softwaredevelopment production management.

Also, according to the present invention, evaluation of actualdevelopment takes into account the work that does not appear in theactual development result due to a specification change which has takenplace in the process of development. The precision of evaluating actualdevelopment is therefore enhanced and the precision of a plansubsequently formed based on the evaluation is accordingly improved.

Also, according to the present invention, evaluation of actualdevelopment takes into consideration matters that are unique to theenvironment of the development and influence the development in a mannerthat removes the influence. A more universal evaluation is thus obtainedbased on actual development, and the precision of a subsequently formedplan is enhanced as a result.

Furthermore, according to the present invention, the abilities ofworkers assigned to the respective work operations are also taken intoaccount in calculating the productivities of the respective workoperations upon planning, and a plan truer to the reality is thusobtained.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram showing the schematic configuration of a softwaredevelopment production management system according to an embodiment ofthe present invention.

FIG. 2 is a function block diagram showing the functional configurationof a software development production management device which is shown inFIG. 1.

FIG. 3 is a diagram showing the flow of processing by a softwaredevelopment production management program which is shown in FIG. 1.

FIG. 4 is a diagram showing processing in Step S1 of the processing flowshown in FIG. 3.

FIG. 5 is a diagram showing processing in Step S2 of the processing flowshown in FIG. 3.

FIG. 6 is a diagram showing processing in Step S3 of the processing flowshown in FIG. 3.

FIG. 7 is a diagram showing processing in Step S4 of the processing flowshown in FIG. 3.

FIG. 8 is a diagram showing processing in Step S5 of the processing flowshown in FIG. 3.

FIG. 9 is a diagram showing processing in Step S6 of the processing flowshown in FIG. 3.

FIG. 10 is a diagram showing processing in Step S7 of the processingflow shown in FIG. 3.

FIG. 11 is a diagram showing processing in Step S8 of the processingflow shown in FIG. 3.

BEST MODE FOR CARRYING OUT THE INVENTION

A software development production management system according to anembodiment of the present invention is described below in detail withreference to the drawings.

As shown in FIG. 1, the software development production managementsystem according to this embodiment has a software developmentproduction management device 1, a terminal 2, which is connected to thesoftware development production management device 1 to serve as a toolof dialogue between a user and the software development productionmanagement device 1, and a management database 3, which storesmanagement information of software development.

More specifically, the software development production management device1 is a computer having a CPU and a storage device. The CPU executes acomputer program read out of the storage device, namely, a softwaredevelopment production management program, thereby building themanagement database 3 in the storage device and forming in the computera standard plan integration module 11, an execution plan creating module12, an actual performance information collecting module 13, a processcompletion monitoring module 14, an actual production performanceevaluating module 15, an individual productivity evaluating module 16,and a function as processing means for controlling the behavior of thesemodules as shown in FIG. 2. The software development productionmanagement program is recorded in a computer-readable format in aportable recording medium such as a CD-ROM or a DVD-RAM, and installedin the storage device when the time to use the program arises.

Registered in the management database 3 are various types of datanecessary for forming and defining a software product development plan,conversion data for canceling out the uniqueness of each softwareproduct and absorbing the difference in ability or other aspects amongengineers who actually participate in the development to thereby presentamore unified view of software product development, and other data. Whenaccessed by the software development production management device 1, themanagement database 3 provides the registered data and performs updateprocessing on the registered data. Specific data and contents registeredin the management database 3 will be described later.

FIG. 3 shows the flow of processing by the software developmentproduction management program according to this embodiment. What followsis a description on the association relation between this flow and thefunction block diagram shown in FIG. 2.

The standard plan integration module 11 performs plan basic informationdefinition (Step S1) and standard development plan creation (Step S2) inFIG. 3. The execution plan creating module 12 performs execution plancreation (Step S3). The actual performance information collecting module13 performs actual performance information input (Step S4), and theprocess completion monitoring module 14 performs project-by-projectfigure aggregation processing (Step S5). The actual productionperformance evaluating module 15 performs developmentunit-by-development unit figure aggregation processing (Step S6), andthe individual productivity evaluating module 16 performs individuals'productivity evaluation aggregation processing (Step S7). The respectiveprocessing will be described below in more detail.

The “plan basic information definition” in this embodiment is composedof, as shown in FIG. 4, 1) defining project development processes(“development process definition”), 2) defining an integration unit(“integration unit definition”), 3) defining a product to be created(“product definition”), 4) selecting or defining activities whichspecifically show work operations carried out to create the product(“activity definition”), 5) defining an environmental variable for theproductivity which influences the productivity of software development(“productivity environmental variable definition”), 6) defining anenvironmental variable for the software product quality which influencesthe productivity of software development (“quality environmentalvariable definition”), 7) defining a conversion reference value forconverting empirical values of software development (“conversionreference value definition”), and 8) inputting a scale plan value of theproduct to be created (“scale plan value input”).

(a) Description of the “Development Process Definition”

Typical software development processes include five phases, in orderfrom the upstream (the upper part of the flow), basic designing, packagedesigning, program creation, integrated test, and system test. All orsome of these five phases are executed depending on, for example,whether the software to be developed is developed initially or developedto have an additional function.

In the software development production management program according tothis embodiment, these typical development processes are prepared inadvance as options, and the user can choose and specify a start processor an end process from among the options on the display screen. The usercan thus easily specify an appropriate start process and end process foreach development system to be managed.

(b) Description of the “Integration Unit Definition”

A software product to be developed is usually composed of multiplesoftware components such as one that performs batch processing and onethat performs online processing. These software components do not alwayshave the same development productivity, and it is necessary inintegrating a software development plan to classify the componentsappropriately by productivity based on the development method anddevelopment language used so that the overall plan value is figured outby counting up the total in each classification category and thenintegrating. Classifying appropriately in preparation for this countingup and integration is the integration unit definition discussed here.

(c) Description of the “Product Definition”

A product is naturally created as a result of the work operations of thedevelopment processes described above. In this embodiment, typicalproducts created in the development processes are prepared in advance asoptions, and the user can define a product of each development processby choosing from among the options. This embodiment is structured suchthat the user can change the name of a product in consideration forcases where the user desires to define a product whose name matches noneof prepared names (for example, cases where a client's request makes theuse of a specific name preferable).

(d) Description of the “Activity Definition”

An activity in this embodiment refers to a work item executed to createa product as the one described above in each development process such asbasic designing and package designing. In this embodiment, work itemsrelevant to the creation of each individual product are sorted into tworanks; work items relevant to the creation of each product are roughlysorted into primary activities and work items sorted into each primaryactivity are called secondary activities. Some work items in effect needonly one rank and, in that case, it is considered that the same workitem belongs to the primary activity and the secondary activity.

This embodiment prepares typical primary activities and secondaryactivities to be selected on the screen, and also allows the user tofreely set work items unique to the software product to be developed onboth the primary activity level and the secondary activity level,thereby providing a flexibility better fit to the reality.

(e) Description of the “Productivity Environmental Variable Definition”

In creating a software development plan, empirical values based on thepast actual development performance are usually employed as theproductivity of software product development. However, the developmentproductivity can be varied by various factors, and the adjustment of thedevelopment productivity needs to take the variation into consideration.In this embodiment, factors that make the development productivity varyare sorted into one due to the quality level required of the softwareproduct (referred to as “quality environmental variable”) and the rest(referred to as “productivity environmental variable”), which aredefined separately.

Productivity environmental variables are defined by defining factorsinto two ranks, such as productivity characteristic and secondaryproductivity characteristic, and determining the influence level of eachfactor in accordance with a characteristic level judgment standard. Thecharacteristic level judgment standard organizes possible changes intolevels for each factor and holds a specific amount of change inassociation with each level.

(f) Description of the “Quality Environmental Variable Definition”

Factors sorted as quality environmental variables, too, are defined intotwo ranks, such as quality characteristic and secondary qualitycharacteristic, and a required quality level is determined for eachfactor in accordance with a required level judgment standard. Therequired level judgment standard organizes possible changes into levelsfor each factor and holds a specific amount of change in associationwith each level.

(g) Description of the “Conversion Reference Value Definition”

It is empirically known that the development productivity and theproduct scale in software development can be varied by various factors.For instance, the productivity and what is written in a product differbetween a software product that controls a plant and a software productthat handles clerical work such as accounting procedures. Withconventional methods where such differences among software products arenot taken into consideration, an appropriate plan cannot be formedunless based on information about a similar software product. Thisembodiment unifies empirical values of the productivity of softwaredevelopment in order to compare individual software product developmentprojects for relative merits.

To elaborate, empirical values of the development productivity ofsoftware development are unified by determining a standard for empiricalvalues of the development productivity of software development (referredto as “cost index standard”). Furthermore, a conversion between the costindex standard and individual software products is accomplished bysetting a conversion reference value for conversion between the unifiedempirical value and values applied to individual software products.

Once a value is registered as the conversion reference value forconversion between the unified empirical value and individual softwareproducts, the value can be reused.

The cost index standard is not an absolute standard but a relativestandard. For example, a software product group in the maximum frequencyzone of an organization that employs the software development productionmanagement system according to this embodiment can be set as thestandard.

The conversion uses the conversion reference value for two purposes.

One is to unify the actual development performance of respectiveproducts of software development into the actual development performanceof a representative product. For instance, a representative productcommon in software development is a source code, and a unified scale isobtained by giving the scale of the source code (in this embodiment, theline count of the source code) as 1 and expressing the scale of eachproduct as a ratio to the source code scale.

The other purpose is to convert a development productivity empiricalvalue for the cost index standard which is kept by the softwaredevelopment production management system into productivities to beapplied to the development of individual software products. The productscale (letter count and page count) of an individual software product isvaried depending on the format of the specification of the softwareproduct, the level of description, and the like. The work amount (time)required to create the product, on the other hand, is varied dependingon what tools are used, how many items and how deeply the items arecontemplated in order to determine the specification, and the like.Since it is empirically known that there is no guarantee that a changein product scale and a change in work amount required to create theproduct are in proportion to each other, this embodiment employs amethod in which a change in product scale with respect to the cost indexstandard and a change in work amount with respect to the cost indexstandard are evaluated independently of each other to convert theproductivity. The productivity is calculated by dividing the work amountby the product scale. When the ratio of the work amount to the costindex standard is given as α and the ratio of the product scale to thecost index standard is given as β, the productivity is converted by thefollowing Expression (1).

Although the scale measure and productivity of software are correlatedwith each other, trying to directly solve the problem of how theproductivity varies without distinguishing a change in product scalefrom a change in work amount, which is what is usually done, producesconfusion. This device evaluates a change in product scale and a changein work amount independently of each other, and can accordingly convertthe productivity without creating confusion.

Converted productivity=(work amount×α)/(productivity scale×β)=(workamount/productivity scale)×(α/β)=cost index standard productivityempirical value×(α/β)  (1)

In this embodiment, an empirical value of the development productivityis kept as a reference value for each product. Multiple activities areassociated with a product, and a set of activities is defined withrespect to an empirical value of the development productivity. Whatactivity belongs to the set is identified by this software developmentproduction management system in advance (the activity is called astandard activity).

A change in work amount is input for each product by specifying theproduct. For each of multiple activities associated with a product, aworkload ratio is kept, which is defined in advance such that the sum ofworkload ratios of the standard activities is 100%. The user identifiesthe ratio of the work amount of each activity to the cost index standardon a factor-by-factor basis, such as a change influenced by a change inwork sophistication level or in amount of a product to be created, andalso identifies whether the change is due to a condition specified bythe client (“specified request”) or due to the ingenuity and technicalcapabilities of the developer (“self-effort”). The user inputs theidentified work amount ratio and “specified request” or “self-effort”.The work amount ratio of a product is calculated by the followingExpression (2).

An effort to improve the work somehow is made on a daily basis, but itis very difficult to translate its effect into a quantitative objectivevalue. With this device, an objective value of the productivity isautomatically obtained for each product when the developer specifies asensible change in work amount in relation to the activity.

Product work amount ratio=Σactivity workload ratio×work amountratio  (2)

The work amount ratio is sorted into “specified request” and“self-effort” in order to measure a rise in development productivity asa result of a work improvement made by the developer's ingenuity andtechnical capabilities. The product of work amount ratios inputseparately for the respective factors of requests specified by theclient is used as a work amount ratio that is varied by a conditionspecified by the client, whereas the product of work amount ratios inputseparately for the respective factors of self-efforts is used as a workamount ratio that is varied by a work improvement made by the developer.

(h) Description of the “Scale Plan Value”

For each product, a development process for initially creating theproduct is determined uniquely. Products created in the respectivedevelopment processes of software development go through changes beforethe system is completed as a result of correction of errors found intests and changes made to the specification. Specifically, an initialproduct of a basic design document is created first in the basicdesigning process, and a part of the basic design document is discardedor a new part is added to the basic design document as a result of achange made to the specification in the package designing process tocreate a realized product, which serves as a basic design documentinitial product when the next program creating process is started.

The amount of the realized product is calculated by adding an amountthat is put on to the amount of the initial product due to the changeand subtracting a scale that is discarded due to the change. The same isrepeated as the development progresses to the subsequent developmentprocesses, to program creation, integrated test, and system test. Inthis embodiment, a product scale estimated or realized at the beginningof an arbitrary development process is called an initially expectedscale, a scale discarded due to a change made to the specificationduring a development process is called a change discarded scale, and ascale added due to a specification change is called a change addedscale.

After the “plan basic information definition” is ended, the “standarddevelopment plan creation” is carried out as shown in FIG. 3. This“standard development plan creation” includes, as shown in FIG. 5,calculating a production plan value (development man-hour anddevelopment labor cost) from a “software development process model”,which is held in the management database 3 in advance, and from the planbasic information, which is input and stored in the management database3 in the preceding “plan basic information definition”, and registeringa development management coefficient, which is an item of management ofthe actual software development performance.

(a) Description of the “Software Development Process Model”

The software development process model is an aggregation of informationfor software development production management that is organized intotables. The table structures and initial values of the respective tablesconstituting the software development production management model areprepared in advance in the management database 3, and updated when thereare inputs from the user in stages of software development productionmanagement according to this embodiment, or when otherwise the needarises.

The tables contained in the software development production managementmodel are listed below:

Development Phase TBL

The development phase TBL is a table holding a development phase ID andthe name of a development process.

Standard Unit Cost TBL

The standard unit cost TBL is a table holding a standard value for thehourly unit cost of the labor cost of a standard work group whichperforms a development work operation associated with a product. Thestandard unit cost TBL may be changed every fiscal year.

Product TBL

The product TBL is a table holding a product ID, a product name, anabbreviated product name, a measure of the product scale (letter count,step count, or the like), and a development phase ID. The developmentphase ID indicates a development phase in which a product in question isinitially created.

Product Productivity Reference Value TBL

The product productivity reference value TBL is a table holding anempirical value of the productivity for each product. The productivityempirical value may be defined every fiscal year so that theorganization's overall improvement in productivity is reflected. In thecase where productivity empirical values used for creation of a newproduct and for modification of an existing product are distinguishedfrom each other, the table may hold productivity empirical values sortedinto an “initial” category and a “change” category.

Primary Activity TBL

The primary activity TBL is a table holding the ID and name of a firstrank activity related to each product.

Secondary Activity TBL

The secondary activity TBL is a table holding the ID and name of asecond rank activity related to each product.

Primary Activity Workload Ratio TBL

Each product is associated with multiple first rank activities. Thistable holds, as a workload ratio, the ratio of work of a first rankactivity to the total work amount of a product with which the activityis associated. In light of ever changing work details of softwaredevelopment due to advancement in technology and the like, the table mayhold new values every fiscal year.

Secondary Activity Workload Ratio TBL

Each first rank activity is associated with multiple second rankactivities. This table holds, as a workload ratio, the ratio of work ofa second rank activity to the total work amount of a primary activitywith which the second rank activity is associated. The table alsoidentifies a second rank activity that constitutes a productivityempirical value defined in the “product productivity reference valueTBL” as belonging to a standard category=‘S’.

Quality Characteristic TBL

The quality characteristic TBL is a table holding the ID and name of aquality characteristic.

Secondary Quality Characteristic TBL

The secondary quality characteristic TBL is a table holding the ID andname of a secondary quality characteristic and a descriptive note of thesecondary quality characteristic.

Quality Characteristic Influence Level TBL

The quality characteristic influence level TBL is a table holding arequired level and specific values in the forms of an influence leveland a quality characteristic specific value range.

Quality Characteristic Primary Activity TBL

The quality characteristic primary activity TBL is a table holding afirst rank activity that is influenced by a secondary qualitycharacteristic and a quality characteristic influence pattern in theforms of a primary activity ID and an environmental variable fluctuationrate pattern ID.

Environmental Variable Fluctuation Rate TBL

The environmental variable fluctuation rate TBL is a table holding afluctuation rate, which is determined by the required level and theinfluence pattern, in the forms of an influence level, an environmentalvariable fluctuation rate pattern ID, and an influence level value.

Productivity Characteristic TBL

The productivity characteristic TBL is a table holding the ID and nameof a productivity characteristic.

Secondary Productivity Characteristic TBL

The secondary productivity characteristic TBL is a table holding the IDand name of a secondary productivity characteristic and a descriptivenote of the secondary productivity characteristic.

Productivity Characteristic Primary Activity TBL

The productivity characteristic primary activity TBL is a table holdinga first rank activity that is influenced by a secondary qualitycharacteristic and a quality characteristic influence pattern in theforms of a primary activity ID and an environmental variable fluctuationrate pattern ID.

Productivity Characteristic Influence Level TBL

The productivity characteristic influence level TBL is a table holding acharacteristic level and specific values in the forms of an influencelevel and a productivity characteristic specific value range.

(b) Description of Information Input in the “Plan Basic InformationDefinition” Kept in the Management Database 3

Information input in the “plan basic information definition”, too, isorganized into tables to be stored in the management database 3. Thetables of information input in the “plan basic information definition”are listed below:

Development Unit Phase TBL

The development unit phase TBL is a table storing a start process and anend process that are associated with a development unit ID in the formsof a start phase ID and an end phase ID.

Integration Unit TBL

The integration unit TBL is a table storing the ID and name of anintegration unit that is defined with respect to a development unit, anda descriptive note of the integration unit.

Integration Unit Phase TBL

The integration unit phase TBL is a table storing, in the form of adevelopment phase ID, a development phase that is a target ofintegration where an integration unit defined with respect to adevelopment unit is used.

Integration Unit Product TBL

The integration unit product TBL is a table storing, in the form of aproduct ID, a product created per integration unit that is defined withrespect to a development unit for each target development phase.

Integration Unit Primary Activity TBL

The integration unit primary activity TBL is a table registering whatfirst rank activity is performed for a product created per integrationunit that is defined with respect to a development phase.

Integration Unit Secondary Activity TBL

The integration unit secondary activity TBL is a table registering whatsecond rank activity is performed for a product created per integrationunit that is defined with respect to a development phase. A record foran activity that is added by the user stores an ID, an activity addedcategory, an added activity name, and an added activity workload ratio.The record may also store the IDs of a quality characteristic and asecondary quality characteristic that are added factors.

Integration Unit Analysis Key TBL

The integration unit analysis key TBL is a table storing definitions ofan analysis key category ID and an actual performance analysis key IDwith respect to an integration unit that is defined with respect to adevelopment unit.

Analysis Key Category TBL

The analysis key category TBL is a table holding the ID and name of atypical analysis key category in advance.

Actual Performance Analysis Key Category TBL

The actual performance analysis key category TBL is a table holding theID and name of a typical actual performance analysis key in advance.

Quality Characteristic Evaluation Result TBL

The quality characteristic evaluation result TBL is a table storing aninfluence level for each secondary quality characteristic as anevaluation result of a quality environmental variable of an integrationunit that is defined with respect to a development unit.

Productivity Characteristic Evaluation Result TBL

The productivity characteristic evaluation result TBL is a table storingan influence level for each secondary productivity characteristic as anevaluation result of a productivity environmental variable of anintegration unit that is defined with respect to a development unit.

Development Unit Cost Index Conversion Standard TBL

The development unit cost index conversion standard TBL is a tablestoring an application conversion standard table.

Cost Index Application Condition TBL

The cost index application condition TBL is a table storing anapplication condition.

Scale Adjustment Coefficient TBL

The scale adjustment coefficient TBL is a table storing a field for thesum of scale adjustment coefficients.

Scale Adjustment Coefficient Specifics TBL

The scale adjustment coefficient specifics TBL is a table storing otherfields than the field for the sum of scale adjustment coefficients.

Activity-By-Activity Workload Adjustment TBL

The activity-by-activity workload adjustment TBL is a table storingworkload adjustment coefficient specifics. An ID for identifying anactivity is copied from the integration secondary activity TBL and thesecondary activity workload ratio TBL. A “baseline workload ratio” inthis table is calculated by the following Expression (3) and stored inthe table:

Baseline workload ratio=workload ratio of primary activity workloadratio TBL×workload ratio of secondary activity workload ratio TBL  (3)

A record for a secondary activity that is added by the user uses theadded activity workload ratio of the integration secondary activity TBLinstead of the workload ratio of the secondary activity workload ratioTBL.

Scale Plan Value TBL

The scale plan value TBL is a table storing a scale plan value input bythe user. In the case where scale plan values are sorted into onescreated in-house and ones created by outsourcing, outsource plan valuesare stored in an outsource scale plan value TBL and in-house plan valuesare obtained by subtracting the outsource scale plan values which areheld in the outsource scale plan value TBL from a total value which isheld in the scale plan TBL.

(c) Description of the “Production Plan Value Calculation”

The “production plan value calculation” of the “standard developmentplan creation” includes 1) calculating a fluctuation rate usingactivity-by-activity productivity environmental variables, 2)calculating a fluctuation rate using activity-by-activity qualityenvironmental variables, 3) converting productivity empirical values, 4)calculating the development man-hour, 5) calculating the developmentlabor cost, and 6) counting up product-by-product plan values, which areexecuted in the order stated. A production plan value is thuscalculated, and the calculation result is stored in the above-describedintegration secondary activity productivity TBL, a product-by-productproductivity TBL, and an estimation value list TBL.

1) Description of the Fluctuation Rate Calculation UsingActivity-by-Activity Productivity Environmental Variables

First, the baseline workload ratio is read out of theactivity-by-activity workload adjustment TBL to be set and stored as theworkload ratio in the integration secondary activity productivity TBL.Next, a productivity associated with the product ID in question is readout of the product productivity reference value TBL. A value obtained bymultiplying the productivity in a record that is sorted as the “initial”category of the initial/change categories by the baseline workload ratiois set as an initial productivity of the integration secondary activityproductivity TBL. A value obtained by multiplying the productivity in arecord that is sorted as the “change” category of the initial/changecategories by the baseline workload ratio is set as a change applicationproductivity of the integration secondary activity productivity TBL.Next, a development unit, the ID of a primary activity relevant to anintegration unit, an environmental variable fluctuation rate pattern ID,and an influence level are read by associating a productivitycharacteristic ID and a secondary productivity characteristic ID in theproductivity characteristic primary activity TBL with a productivitycharacteristic ID and a secondary productivity characteristic ID in theproductivity characteristic evaluation result TBL. Next, theenvironmental variable fluctuation rate pattern ID and the influencelevel are used to read an influence level value out of the environmentalvariable fluctuation rate TBL. Since there are multiple pairs of aproductivity characteristic ID and a secondary productivitycharacteristic ID for each primary activity ID, and an influence levelvalue is held for each of the pairs, the sum of influence level valuesof all pairs of a productivity characteristic ID and a secondaryproductivity characteristic ID that are associated with a primaryactivity is used as a productivity characteristic influence rate of theprimary activity. This productivity characteristic influence rate of theprimary activity is set and stored as a productivity characteristicinfluence rate in a record of the integration secondary activityproductivity TBL that has the matching primary activity ID.

2) Description of the Fluctuation Rate Calculation Using theActivity-by-Activity Quality Environmental Variable

A development unit, the ID of a primary activity relevant to anintegration unit, an environmental variable fluctuation rate pattern ID,and an influence level are read by associating a quality characteristicID and a secondary quality characteristic ID in the qualitycharacteristic primary activity TBL with a quality characteristic ID anda secondary quality characteristic ID in the quality characteristicevaluation result TBL. Next, the environmental variable fluctuation ratepattern ID and the influence level are used to read an influence levelvalue out of the environmental variable fluctuation rate TBL. Sincethere are multiple pairs of a quality characteristic ID and a secondaryquality characteristic ID for each primary activity ID, and an influencelevel value is held for each of the pairs, the sum of influence levelvalues of all pairs of a quality characteristic ID and a secondaryquality characteristic ID that are associated with a primary activity isused as a quality characteristic influence rate of the primary activity.This quality characteristic influence rate of the primary activity isset and stored as a quality characteristic influence rate in a record ofthe integration secondary activity productivity TBL that has thematching primary activity ID.

3) Description of the Productivity Empirical Value Conversion

Self-effort scale adjustment coefficients and specified request scaleadjustment coefficients, which are registered on an integration unitbasis and on a product ID basis, are read out of the scale adjustmentcoefficient TBL. Next, from records of the activity-by-activity workloadadjustment TBL that have the same product ID, self-effort workloadadjustment coefficients and specified request workload adjustmentcoefficients are read. Records having the same primary activity ID andthe same secondary activity ID are then read out of the integrationsecondary activity productivity TBL to re-calculate the initialapplication productivity and the change application productivity asfollows. The re-calculated productivities are stored in the integrationsecondary activity productivity TBL.

Initial application productivity=initial applicationproductivity×(1+productivity characteristic influence rate+qualitycharacteristic influence rate)×self-effort workload adjustmentcoefficient×specified request workload adjustmentcoefficient/self-effort scale adjustment coefficient/specified requestscale adjustment coefficient

Change application productivity=Change applicationproductivity×(1+productivity characteristic influence rate qualitycharacteristic influence rate)×self-effort workload adjustmentcoefficient×specified request workload adjustmentcoefficient/self-effort scale adjustment coefficient/specified requestscale adjustment coefficient

4) Description of the Development Man-Hour Calculation and theDevelopment Labor Cost Calculation

In the integration secondary activity productivity TBL, initialapplication productivities and change application productivities thathave the same system ID˜productivity ID are counted up to obtainproduct-by-product productivities. The calculation results are stored inthe product-by-product productivity TBL.

Next, the initially expected scales and the change scales are read outof the outsource scale plan value TBL to calculate the outsource initialman-hour (=outsource initially expected scale×initial productivity ofproduct-by-product productivity TBL) and the outsource change man-hour(=outsource change scale×change productivity of product-by-productproductivity TBL). The outsource initial man-hour and the outsourcechange man-hour are multiplied by a standard per-process-step-time unitcost in the standard unit cost TBL that has the matching product ID, tothereby obtain the labor cost. The calculation results are stored in anoutsource production plan value TBL.

Next, the initially expected scales and the change scales are read outof an in-house scale plan value view to calculate the in-house initialman-hour (=in-house initially expected scale×initial productivity ofproduct-by-product productivity TBL) and the in-house change man-hour(=in-house change scale×change productivity of product-by-productproductivity TBL). The in-house initial man-hour and the in-house changeman-hour are multiplied by a standard per-process-step-time unit cost inthe standard unit cost TBL that has the matching product ID, to therebyobtain the labor cost. The calculation results are stored in an in-houseproduction plan value TBL.

Next, the sum of plan values read out of the outsource production planvalue TBL and the in-house production plan value TBL is calculated andstored in the estimation value list TBL. The sum is calculated asfollows:

Product scale=(outsource initially expected scale+in-house initiallyexpected scale)+(outsource change scale+in-house change scale)−(outhousediscarded scale+in-house discarded scale)

Standard man-hour=(outsource initial man-hour+outsource changeman-hour)+(in-house initial man-hour+in-house change man-hour)

Standard labor cost=(outsource initial labor cost+outsource change laborcost)+(in-house initial labor cost+in-house change labor cost)

Productivity=standard man-hour/product scale

(d) Description of the Development Management Coefficient Registrationin the “Standard Development Plan Creation”

A development management coefficient is an item for comparing a planvalue and actual performance value of software development. Thisembodiment assigns each product multiple measurement items, which arestored as a measurement item TBL in the management database 3.Specifically, the table structure and initial values of the measurementitem TBL are registered in the management database 3 in advance, and canbe modified at the user's discretion. When the user selects ameasurement target item and registers a plan value, the data is storedin the development management coefficient TBL. Data stored in thedevelopment management coefficient TBL is printed out as a developmentmanagement coefficient report and used as objective values of itemsmonitored while the software development is in progress.

The completion of the “standard development plan creation” is followedby the “execution plan creation” (see FIG. 3). This “execution plancreation” specifically includes, as shown in FIG. 6, “software item” and“work item” registration, and subsequent “work item-by-work item workplan registration”.

(a) Description of the “Software Item”

Software items are segmentalized realized functions and the like thatare treated as the management unit in managing the configuration of asoftware product. In software development, usually persons who handlethe development, realized functions, and the like are segmentalized inconcert with the progress of the processes.

The user registers the integration unit, development processes and, foreach product, software items treated as the management unit.Specifically, because a scale plan value has been input for each productin the standard development plan, the user segmentalizes this to input ascale plan value for each software item.

The data input by the user is stored in a software item TBL in themanagement database 3. Software items which are realized functions aresequentially segmentalized and defined, which makes it possible todiscriminate realized functions that have not been segmentalized yet bydisplaying them as dummies.

(b) Description of the “Work Item”

When the registered software items as the management unit are actuallyassigned to a person who handles the software development, more than oneperson may be assigned if the management unit is large. For instance,user interface designing work and database designing work of onerealized function are treated as one operation by the realized function,but, in that case, the user interface designing work and the databasedesigning work are usually separated and assigned to different persons.A unit obtained by further segmentalizing management unit work in thismanner in order to assign the work to persons who handle softwaredevelopment is a work item.

Management unit development work can be identified on an activity basissince a product is associated with activities. A work item is definedand registered as a set of activities to be assigned to persons whohandle development.

The defined and registered work item is stored in a work item managementTBL and work item secondary activity TBL of the management database 3.The work item management TBL holds the work item management number andwork item name of a work item defined by the user. The work itemsecondary activity TBL holds the ID of a secondary activity contained ina work item. A list of secondary activities is created from theintegration secondary activity TBL, which has been created in thestandard development plan creation, and the user selects activities tobe included in a work item from the list.

(c) Description of the “Work Item-by-Work Item Work Plan”

The work item-by-work item work plan is a plan that assigns units ofwork allocation to persons which are registered as work items to actualpersons who handle development. The development productivity set in thestandard development plan is a mean value based on past empiricalvalues. Since software development experience and ability differ fromperson to person, when the user assigns work to an actual person, thedevelopment productivity has to be modified into one that is fit to theexperience and ability of the person.

In this embodiment, the productivity is modified by making a correctionas follows. The corrected productivity is stored in a production workmanagement unit TBL of the management database 3.

1) Description of Correction by Salary

In this embodiment, an hourly unit cost which is determined by a salaryis set in advance to each person who handles development, and the hourlyunit cost is kept in the management database 3 to obtain a developmentproductivity associated with an individual person by the followingexpression:

Productivity of individual person=(standard developmentman-hour×standard per-process-step-time unit cost)/individual's hourlyunit cost=standard development man-hour×(standard per-process-step-timeunit cost/individual's hourly unit cost)

The integration secondary activity productivity TBL created in thestandard development plan creation in this embodiment holds adevelopment productivity on a secondary activity basis. Thisproductivity is multiplied by the scale of a software item defined inthe software item TBL to obtain the standard development man-hour ofeach secondary activity. The standard development man-hour calculatedfor each secondary activity is sorted by work item management numberdefined in the work item secondary activity TBL, and counted up toobtain the standard man-hour for each work item management number.

2) Description of Correction by Ability

In this embodiment, a coefficient for correcting a person's ability isheld for each product as a person-by-person productivity correctioncoefficient in a personnel-by-personnel productivity correction TBL ofthe management database 3. The coefficient is the ratio of a per-unitamount price of a product created in the past by a person in question toan average per-unit amount price of the products. This embodiment usesthis relative ability coefficient to make a correction such that a valueobtained by multiplying an individual person's productivity by therelative ability coefficient is used as the development productivity.The person-by-person productivity correction coefficients stored in thepersonnel-by-personnel productivity correction coefficient TBL areresults of analyzing the actual production performance of individualpersons in the individuals' productivity evaluation aggregationprocessing, which will be described later.

3) Description of Other Corrections

Other corrections include a correction of man-hour that is independentof individual persons' experience and ability, such as acquiringknowledge necessary for software development of a new business operationand redoing the work of a previous step due to an error in a masterdesign document. This type of correction is made by the user directlyspecifying a corrected man-hour, and the result is stored in apersonnel-by-personnel correction man-hour TBL. Another correctedman-hour may be entered after sorted by reason of correction.

As shown in FIG. 3, the completion of the “execution plan creation” isfollowed by the “actual performance information input”. This “actualperformance information input” specifically includes, as shown in FIG.7, inputting “actual man-hour performance”, a “predicted remainingman-hour”, “actual production scale performance”, “actual reviewperformance”, “actual bug performance”, and a “memorandum”. Once input,these are organized into tables to be stored in the management database3. What is input as these will be described below.

(a) Description of the “Actual Man-Hour Performance”

In this embodiment, the actual man-hour performance of individualpersons can be input on a work item basis and on a secondary activitybasis. Specifically, each input screen can be identified by a person'sname and a date, and is designed such that the actual man-hourperformance can be input on a second rank activity basis on the screen.Data input on the screen is stored as a person-by-person actual man-hourperformance TBL in the management database.

The actual man-hour performance input may not be daily performance, butmay be weekly or monthly performance, or performance measured in adevelopment phase or other production management cycles determined bythe developer organization.

An outsource actual performance registration function or the like isprepared so that the user can input the actual man-hour performance ofoutsourced work on the screen. The thus input data is stored in anactual outsource man-hour performance TBL.

(b) Description of “Predicted Remaining Man-Hour”

In order to grasp the progress on a work item basis, remaining man-hoursand remaining development amount till the completion of work in the workitem of each person are entered and the inputs are organized into atable to be stored in a remainder prediction TBL. The inputs make itpossible to grasp the man-hour consumption rate and the product creationrate for each work management unit at that point, which can be used inwork progress management and enables the overseer to refer at any timeto an opinion of a person who handles development about deviation fromthe planned man-hour.

(c) Description of the “Actual Review Performance”

Actual review performance such as the time spent for review, pointed-outreasons, and the case count is also beneficial information formanagement of the quality of a software product. Such information istherefore registered as actual review performance in the managementdatabase in this embodiment. This registration function is an arbitraryfunction and may be omitted.

(d) Description of the “Actual Bug Performance”

Information about a found bug such as why the bug has slipped in, whichproduct contains the bug, and the case count is also beneficial formanagement of the quality of a software product. Such information istherefore registered as actual bug performance in the managementdatabase in this embodiment. This registration function is an arbitraryfunction and may be omitted.

(e) Description of the “Memorandum”

Software development work is theoretically allocated among individualpersons by creating an execution plan but, in practice, is cooperativework by multiple persons in most cases. For convenience of explanation,persons assigned to respective work operations are referred to as“instructed persons”. In the execution plan, there is one instructedperson for one work item. The instructed person performs softwaredevelopment work such as designing and programming on an input product,to thereby create an output product. In the process of conductingsoftware development work, the instructed person asks other people foradvice or guidance and, in some cases, argue with other people. Theperson's work efficiency rises when the advice or guidance is goodwhereas it drops when the advice or guidance is irrelevant. A personthat gives advice to or guides an instructed person is referred to as“instructor”. There may be only one instructor, or two or moreinstructors.

The memorandum is for recording what advice or guidance has been givenby an instructor in order to evaluate how much the instructor's adviceor guidance has contributed to the work efficiency. The user can inputthe man-hour spent for the advice and details of the advice on thescreen, and the inputs are stored in a memorandum-instructed person TBLand a memorandum-instructor TBL.

After the “actual performance information input” is ended, the“project-by-project figure aggregation processing” and the “developmentunit-by-development unit figure aggregation processing” are executedsuccessively (see FIG. 3). The “project-by-project figure aggregationprocessing” includes, as shown in FIG. 8, registration of “phasecompletion” and “system development completion (project completion)”,and counting up of various figures. The “development unit-by-developmentunit figure aggregation processing” includes, as shown in FIG. 9,registration of development unit completion and evaluation of a softwaredevelopment process model which is conducted by evaluating the actualproduction performance.

(a) Description of the “Phase Completion Registration”

The phase completion registration is registration that should be madeeach time a development process such as basic designing and packagedesigning is finished to record the completion of the process.Specifically, the phase completion registration is accomplished bymaking “completion date registration” and “actual environmental variableperformance registration”. In this embodiment, by registering thecompletion date of a phase, inputting actual work performance after thecompletion date is prevented and a function is added which registers aresult of assessment of development process completion such as anadequacy check self-rated score.

The phase completion registration is followed by “test issue submissioncoefficient registration”. Specifically, processing of aggregating dataupon completion of the phase is executed, an item and plan value to bemeasured are read out of the development management coefficient TBL,which has been created in the standard development plan, and an actualperformance value is read out of an actual development managementcoefficient performance TBL to be displayed on the screen. Based on thedisplayed data, the user inputs or updates an actual performance valueto store or update the actual performance value in the actualdevelopment management coefficient performance TBL. Actual performanceof a work item or the like that differs from its estimation may be inputif the user requests.

1) Description of the “Actual Environmental Variable PerformanceRegistration”

In the “plan basic information definition”, information at the time ofplanning (at the time of estimation) has been input as the “productivityenvironmental variable definition” and the “quality environmentalvariable definition”. As information corresponding to this information,the factors are reevaluated upon completion of a development phase andinput in the “actual environmental variable performance registration”.What is registered in the “actual environmental variable performanceregistration” is substantially the same as the “productivityenvironmental variable definition” and the “quality environmentalvariable definition” in the “plan basic information definition”, butreflects the actual performance at the time of completion of thedevelopment phase. The information input by the user is stored in anactual productivity characteristic performance evaluation result TBL, anactual quality characteristic performance evaluation result TBL, and anactual scale performance correction TBL.

After these tables are created, the created tables are used to calculatea “productivity characteristic influence rate” and a “qualitycharacteristic influence rate” in a manner similar to the “productionplan value calculation” in the “standard development plan creation”.Specifically, the “actual productivity characteristic performanceevaluation result TBL” is used instead of the “productivitycharacteristic evaluation result TBL” and the “actual qualitycharacteristic performance evaluation result TBL” is used instead of the“quality characteristic evaluation result TBL” in a calculation similarto the “productivity plan value calculation” in the “standarddevelopment plan creation” described above, to thereby calculate the“productivity characteristic influence rate” and the “qualitycharacteristic influence rate”. On the screen, a value obtained by{productivity characteristic influence rate+quality environmentalcharacteristic influence rate}×100 is displayed as an influence ratetheoretical value. This is the rate of influence to the productivity bythe productivity characteristic and the quality characteristic that havebeen re-evaluated upon completion of the phase, and the user can use thedifference between this and the rate of influence to the productivitythat has been calculated at the time of planning as an error inproductivity characteristic and quality characteristic evaluation. Theevaluation error can be used as a chance to improve the method ofevaluating the productivity characteristic and the qualitycharacteristic.

2) Description of the “Aggregation Processing upon Phase Completion”

Information other than the one registered in the “actual environmentalvariable performance registration” described in the above Section 1)includes information that is stored in the “actual performanceinformation input” in the management database 3 as the “person-by-personactual man-hour performance TBL”, the “actual production scaleperformance TBL”, the “actual outsource man-hour performance TBL”, andan “actual outsource scale performance TBL”.

These tables are used when aggregation target items are read out of themeasurement item TBL upon request from the user. The respectiveaggregation target items are read out of the person-by-person actualman-hour performance TBL, the actual production scale performance TBL,the actual outsource man-hour performance TBL, and the actual outsourcescale performance TBL to be aggregated. The result of the aggregation isstored in the actual development management coefficient performance TBL.The aggregation result is displayed on the display screen and alsoprinted by a printer. The aggregation result includes a comparisonbetween activities planned to be executed in the software developmentwork and actually executed activities, an aggregation result of softwareitem-by-software item actual product scale performance, the mean valueand standard deviation of test densities (the count of test items persource code line), and the like. The mean value and standard deviationof bug densities (the count of errors (bugs) found in a test per sourcecode line) and a result of comparison between a plan value stored in thedevelopment management coefficient TBL and an actual performance valuestored in the actual development management coefficient performance TBLare also information that can be used for the purpose of promptingimprovement of software development work.

As the actual production scale performance, the scale of an actuallycreated document or program source may be measured automatically byreading the document or program source.

(b) Description of the “System Development Completion (ProjectCompletion) Registration”

After the series of phases up through the system test is all finished, adevelopment unit completion date is registered. When the user enters aninstruction on a given screen to perform a development completioncalculation, the completion date of the final development phase of thedevelopment unit is stored as the development unit completion date in adevelopment unit completion TBL.

(c) Description of Information Aggregable through the “DevelopmentUnit-by-Development Unit Figure Aggregation Processing”

The management database 3 stores information input in the “phasecompletion registration” and the “actual performance information input”.The stored information receives given aggregation processing beforedisplayed on the screen upon request from the user and, in response to afurther request, is printed by a printer. The displayed aggregationresult is, for example, a list of differences and disparity ratesbetween plan values and actual performance values that are stored in thedevelopment management coefficient TBL and the actual developmentmanagement coefficient performance TBL, respectively. In thisembodiment, the aggregation unit may be a development phase, anintegration unit, or a combination of development phases and integrationunits, and can be specified by the user at his/her discretion.

It is understood from FIG. 3 that the “individual-basis productivityevaluation aggregation processing” is executed in parallel with the“project-by-project figure aggregation processing” and “developmentunit-by-development unit figure aggregation processing” described above.In other words, the “individual-basis productivity evaluationaggregation processing” is also executed after the “actual performanceinformation input” is finished.

The “individual-basis productivity evaluation aggregation processing”includes, as shown in FIG. 10, “evaluation basic informationaggregation”, “inter-organization relative evaluation correction input”,and “individuals' productivity evaluation aggregation”. In the“evaluation basic information aggregation”, evaluation basic informationis created for each instructor and each instructed person, and a listfor adjustment within a team is output. Next, adjustments are madesequentially from the lower echelon of the organization to the upperechelon so that an adjustment within the software development projectteam is made first, then an adjustment within the section, and then anadjustment within the department. The adjustment results are made intoan adjustment result list. A difference between organizations isadjusted by the “inter-organization relative evaluation correctioninput”. The adjustment result list is a ranking list of individuals'product-by-product productivities. Results of the company-wideadjustment are stored in the personnel-by-personnel productivitycorrection TBL. This personnel-by-personnel productivity correction TBLis consulted in the future when an execution plan is created indevelopment production management of another software product in orderto correct differences in ability among individuals. Therefore,according to this embodiment, differences in ability among individualscan be reflected on a plan based on the past record of development,which makes it possible to raise the precision of a plan progressivelyand to reflect an improvement in ability of individual persons on theplan as seen fit.

In the “individuals' productivity evaluation aggregation” processingexecuted next, an individual-basis ranking list is created by compilingthe instructor ranking list and the instructed person ranking list. Acertain reference line is set to section this ranking list so that theuser can determine individuals' ratings in regard to softwaredevelopment productivity, and the ranking list can be used as referenceinformation in personnel review of persons who handle softwaredevelopment.

(a) Description of the “Evaluation Basic Information Aggregation”

The evaluation basic information aggregation is composed of “softwareitem completion input”, “basic data additional input”, and “reducingeffect registration”.

1) Description of the “Software Item Completion Input”

On the screen, the user checks each software item for its completedsection and gives an instruction to save, causing the completed sectionto be stored in a software item completed section TBL. At the time anindividual's productivity is evaluated, some software items are beingworked on whereas other software items have been completed. The softwareitem completion input is for evaluating the productivity by using theactual performance value for a completed software item and using theplan value created in the execution plan for a software item that isbeing worked on.

In this embodiment, the actual performance value of the man-hour and theplan value of the man-hour are read out of the person-by-person actualman-hour performance TBL and the production work management unit TBL,respectively, to create a record in an evaluation target man-hour TBL.Also, the actual performance value of the scale and the plan value ofthe scale are read out of the actual production scale performance TBLand the production work management unit TBL, respectively, to create arecord in an evaluation target scale TBL.

2) Description of Additional Input of Evaluation Basic Information

While the information input in the “work item-by-work item work plan”may be used as evaluation basic information, this embodiment alsoprovides a way for the user to additionally input evaluation basicinformation. Specifically, the actual man-hour performance ofinstructors and the actual man-hour performance of instructed personsare counted up on a work item basis to be displayed in actual man-hourperformance fields, and corrected man-hour breakdown fields are providedin association with the actual man-hour performance fields. The userenters information in the corrected man-hour breakdown fields and theinformation is stored in a correction-accommodating man-hour TBL. Theinformation input by the user is listed below:

Skill Correction Man-Hour

The skill correction man-hour is the man-hour necessary for compensatingfor a person's lack of skill in work in question (for example, necessaryfor learning a work procedure or applied technique of a developmentprocess that the person experiences for the first time). For fairevaluation of individual persons' productivities, a correction is madeby subtracting the skill correction man-hour from the person's actualwork man-hour performance.

Contrivance Effect Correction Man-Hour

The contrivance effect correction man-hour is the man-hour that can bereduced in work in question owing to an idea thought up of by anotherperson who is handling the software development. Since the credit ofreducing the work man-hour goes to the other person and not the personin question, a correction is made by adding the contrivance effectcorrection man-hour to the actual work man-hour performance of theperson in question.

Difficulty Level Correction Man-Hour

The difficulty level correction man-hour is the man-hour added due to ahigh difficulty level unique to a software item assigned to a person.For fair evaluation of individual persons' productivities, a correctionis made by subtracting the difficulty level correction man-hour from theperson's actual work man-hour performance.

Change-Accommodating Correction Man-Hour

The change-accommodating correction man-hour is the man-hour for redoinga previous step due to a change in specification. For fair evaluation ofindividual persons' productivities, a correction is made by subtractingthe change-accommodating correction man-hour from the person's actualwork man-hour performance.

Problem-Accommodating Correction Man-Hour

The problem-accommodating correction man-hour is the man-hour forredoing a previous step to rectify an error in a superordinate productthat is created by not the person in question but another person who ishandling the software development. For fair evaluation of individualpersons' productivities, a correction is made by subtracting theproblem-accommodating correction man-hour from the person's actual workman-hour performance.

When such information is input, the evaluation target man-hour iscalculated by the following expression to be stored in a calculationresult TBL. The actual man-hour performance is read out of theperson-by-person actual man-hour performance TBL.

Post-correction evaluation target man-hour=actual man-hourperformance−skill correction man-hour+contrivance effect correctionman-hour−difficulty level correction man-hour−change-accommodatingcorrection man-hour−problem-accommodating correction man-hour

An instructed person cost is obtained by multiplying the post-correctionevaluation target man-hour by an hourly unit cost, which is read out ofan individual-by-individual hourly cost TBL. The instructed person costis divided by an evaluation target scale, which is read out of theevaluation target scale TBL.

3) Description of the Reducing Effect Registration

The reducing effect registration is to input an assessed effect ofadvice given by an instructor which is assessed based on the memorandumentered in the actual performance information input. Registered data isread out of the memorandum-instructor TBL and the memorandum-instructedperson TBL to be displayed in the form of a list on the display screenupon request from the user. The user sections a range between −10% and+100% at 10% intervals, and inputs one of the levels “−1˜10” as aneffect level, which is the degree of reduction in a work man-hour owingto advice, to assess the effect of the advice. Specifically, when aneffect level is input, values for ranking instructors and instructedpersons are calculated based on the input effect level.

α) Value for Ranking Instructors

Instructors are ranked in descending order of value obtained by dividingan effect amount in money by a cost that is put in as an instructor(hereinafter referred to as “effect rate”).

The effect amount in money is a reduced cost halved between aninstructor and an instructed person. The reduced cost refers to a costcut owing to the instructor's instruction, and is an amount of moneycalculated by subtracting the instructed person's cost that has actuallybeen required from the instructed person's cost that would have beenrequired if the instructor has not given the advice (hereinafterreferred to as a predicted input cost). The reduced cost is halvedbetween the instructor and the instructed person because it isconsidered that eliciting more effective advice, too, is an individual'sability. The degree of reduction in a work man-hour as a result ofgiving advice is stored as the effect level. The unit of effect level is10%. Accordingly, the ratio of the man-hour that is considered to bereduced owing to the advice is calculated by “1−effect level/10”. Theactually worked man-hour is a reduced man-hour that has been reduced asa result of receiving the advice, and the work man-hour that would havebeen required if the instructor has not given the advice is calculatedby dividing the actual work man-hour by (1−effect level/10). The cost iscalculated by multiplying the workman-hour by an individual's hourlyunit cost, and a predicted input cost is calculated by the followingexpression. An instructed person's cost is the amount of moneycalculated by multiplying the post-correction evaluation target man-hourby the individual's per-hour cost, and has been corrected using theresult of additional input of the evaluation basic information.

Predicted input cost=(instructed person's cost+instructor'scost)/(1−effect level/10)

The reduced cost is obtained as follows:

Reduced cost=predicted input cost−(instructor's cost+instructed person'scost)

The above expressions cannot be used when the effect level is 10, inother words, when the degree of reduction is 100%. In this case, theamount of money calculated by multiplying the actual average costperformance per unit amount of product by the product amount is treatedas the reduced cost.

The effect amount in money is calculated as follows:

Effect amount in money=reduced cost/2

(β) Value for Ranking Instructed Persons

Instructed persons are basically ranked by cost per unit product amount(hereinafter referred to as “individual's productivity”). However, thisranking method cannot be used as it is since the developmentproductivity of software development is varied by a difference betweensystems to be developed and a difference in integration unit even whenthe same product is created. For that reason, the mean value of per-unitproduct amount costs (hereinafter referred to as average productivity)is calculated under the condition that the same development system andthe same integration unit are used to create the same product. A valueobtained by dividing the per-unit product amount cost of a product thatis created by an individual by the average productivity (hereinafterreferred to as individual's relative productivity) is used for theranking. The individual's relative productivity indicates how far anindividual's productivity is from the average. When the individual'srelative productivity is smaller than 1, it means that the individual iscreating a product cheaper than average and, when larger than 1, itmeans that the individual is creating a product that is more costly thanaverage. Instructed persons are therefore ranked in ascending order ofindividual's relative productivity.

Individual's productivity=(instructed person's cost+instructor'scost+reduced cost/2)/product amount

Individual's relative productivity=individual's productivity/averageproductivity

An instructed person together with an instructor handles an activitywhich is a part of work of outputting a specific process product,namely, a software item. It is not practical to directly measure thescale of a product output by the activity that is assigned to theperson, of the specific process product, namely, the software item to beoutput, in light of cost required for the measurement. This embodimenttherefore uses as the product amount a logical product scale obtained asfollows. The scale of an actual process product (software item) isprorated in accordance with the workload ratio of a secondary activity,which has been stored in the integration secondary activity productivityTBL when creating the standard development plan. The logical scale of aproduct associated with this activity is thus obtained. The scale of theactual process product (software item) is stored in the actualproduction scale performance TBL, and a scale calculated by “ultimatelyrealized scale−start-up scale+net scale” is used.

(b) Description of “Inter-Organization Relative Evaluation CorrectionInput”

The contribution rates of instructors and the individuals'productivities of instructed persons are aggregated on a product basisand on a person-by-person basis to create a ranking list.

The ranking list shows relative ranks among the members of the projectteam, the section, and the department. As the matrix is expanded fromthe project team to the section and from the section to the department,uneven distribution of members must be corrected. This embodiment allowsthe user to input a correction coefficient to correct the unevendistribution on the screen. The result of the input is stored in thedevelopment unit-by-development unit productivity TBL, asection-by-section productivity TBL, a department-by-departmentproductivity TBL, and a company-wide productivity TBL. After inputtingthe correction coefficient, the user causes the result of the adjustmentto be output, checks the adjustment result, and ends the adjustmentbetween organizations. This is repeated until the adjustment iscompleted company-wide.

In this embodiment, where the user is allowed to input a correctioncoefficient to correct the uneven distribution of members on the screen,the correction may be made automatically by registering a correctioncoefficient in advance. The assumption of this is that a stage where thecorrection method and the correction standard are satisfactorily stableis reached before automating the operation by advance registration.

α) Aggregation of Contribution Rates of Instructors

A post-correction contribution amount in money is calculated bymultiplying the contribution amount in money by a correction coefficientthat the user inputs. In the case where the user does not specify acorrection coefficient, 1.0 is used as the correction coefficient. Next,instructors' post-correction contribution amounts in money andinstructors' input costs are counted up for each person who handles thesoftware development and for each product on an integration unit basis.A contribution rate is obtained by dividing the tallied-up individuals'contribution amounts in money by the tallied-up individual instructors'input costs.

β) Aggregation of Individuals' Relative Productivities of InstructedPersons

Individuals' productivities of instructed persons are aggregated on thepremise that any combination of a development system and an integrationunit produces the same value as the average productivity. In otherwords, a correction coefficient input by the user is used as a valuethat determines the relative values of the average productivity producedby one development system and one integration unit and of the averageproductivity produced by a different development system and a differentintegration unit. Individuals' relative productivities are correctedwith the correction coefficient as follows:

Post-correction individuals' relative productivities=individuals'productivities/(average productivity×correctioncoefficient)=individuals' relative productivities/correction coefficient

After the post-correction individuals' relative productivities areobtained, the individuals' productivities of instructed persons areaggregated in the following manner. When no correction coefficient isset, 1.0 is used as the correction coefficient. Post-correctionindividuals' relative productivities×product amounts and product amountsare counted up. The tallied-up post-correction individuals' relativeproductivities×product amounts is divided by the tallied-up productamounts to obtain the individuals' relative productivities.

(c) Description of “Individuals' Productivity Evaluation AggregationProcessing”

Up to this point, the product-by-product ranking lists for instructorsand for instructed persons have been created. In this embodiment, acontribution amount in money is calculated by the following expressionto create an individual-basis ranking list. The instructors'contribution amounts in money are the tallied-up value of thepost-correction contribution amounts in money which have been ultimatelycorrected through the inter-organization relative evaluation correctioninput. The company-wide productivity TBL is read to count up the readdata for each employee number, and the result is stored in anindividual-basis evaluation compiling TBL. An instructed person'scontribution amount in money is defined as a development cost at whichthe instructed person has succeeded in creating a product cheaper thanthe mean value of per-unit amount costs of the products. Each personhandling software development may work as an instructor in some stageswhile working as an instructed person in other stages. Therefore, anadded value rate is calculated by the following expression and thepersons are sorted in descending order of added value rate, thuscreating an individual-basis ranking list.

Added value rate=(Contribution amount in money asinstructor+contribution amount in money as instructed person)/(cost asinstructor+cost as instructed person)

After the “development unit-by-development unit figure aggregationprocessing” and the “individual-basis productivity evaluationaggregation processing” are ended, “aggregation processing” is executedsubsequently. This “aggregation processing” is specifically composed of“actual production performance aggregation processing” and “planreference value update”.

(a) Description of “Actual Production Performance AggregationProcessing”

Actual performance information aggregated upon completion of a phase andactual performance information aggregated upon completion of a projectare stored in the management database 3 by the project-by-project figureaggregation processing and the development unit-by-development unitfigure aggregation processing.

The actual production performance aggregation processing includes 1)index value calculation through which actual cost index performanceinformation is stored in the management database 3 and 2) index valuereference through which an analysis result is output. The index valuecalculation processing is executed upon request from the user and theresult of the processing is stored in the actual cost index performanceinformation of the management database 3.

In this embodiment, the user can specify through the display howreference information is output by specifying an index value category, acycle, and a comparison method. Information that can be referred to isclassified into index value category, cycle, and comparison method.Index values actually referred to are sorted into two ranks, primaryindex values and secondary index values. Examples of the analysis resultinclude a fiscal year-basis comparison table, a matrix-basis rankingtable, an improvement rate ranking table, and a graph showing therelation between measurement items. The fiscal year-basis comparisontable is for grasping the degree of improvement by comparison with thepreceding fiscal year. The matrix-basis ranking table is used to graspwhich one of projects, or which one of organizations, is superior orinferior and thereby find where to improve, and to expand the superiorpoints to the other organizations. The inter-measurement item relationgraph can be used to, for example, find and evaluate a productivityprediction formula by analyzing the scale-cost correlation, and to findand evaluate a product scale prediction formula by analyzing the scalecorrelation between a superordinate product and a subordinate product.Since the actual performance is accumulated project after project in themanagement data base 3, prediction formulae of progressively higherprecision can be created from the accumulated information.

1) Description of Index Value Calculation

The index value calculation is to calculate a cost index. In thisembodiment, project-by-project cost index plan values,project-by-project cost index actual performance values, andengineer-by-engineer cost index actual performance values are calculatedand stored in a project-by-project cost index TBL.

In calculating a cost index, first, the result of executing basicinformation editing processing is stored in a cost index standard TBL.Information in the cost index standard TBL is read next to executeremodeling product cost index compiling processing, and the result ofthe processing is stored in an aggregated cost index standard TBL.Lastly, information in the aggregated cost index standard TBL is read toexecute product-by-product cost index compiling processing, and theresult of the processing is stored in a project-by-project cost indexstandard TBL.

In the basic information editing processing, quantity-based costcalculation is performed first, in which the individual-by-individual,project-by-project, and secondary activity-by-secondary activity laborcosts are read out of the person-by-person actual man-hour performanceTBL, and counted up for each combination of a system ID, a developmentunit ID, a project ID, an integration unit ID, and a product ID. Next,ultimately realized scales are read out of the actual production scaleperformance TBL, and counted up for each same combination of a systemID, a development unit ID, a project ID, an integration unit ID, and aproduct ID. The quantity-based cost is calculated by dividing theaggregated labor cost value by the aggregated ultimately realized scalevalue.

Next, a change in productivity due to the development environmentcharacteristic and a change in productivity due to the qualitycharacteristic are eliminated. Σ environmental variable influence rateis read out of an actual integration performance secondary activity TBL,and the quantity-based cost is divided by (1+Σ environmental variableinfluence rate) to obtain a post-environmental variable influence rateelimination quantity-based cost.

Work for creating one product differs from project to project, andinfluence of this difference is eliminated by converting thequantity-based cost into the quantity-based cost of a case where work isdone under the standard activity distribution. In this embodiment, awork operation is identified by a secondary activity ID. The ID of asecondary activity carried out in a project is stored in the actualintegration performance secondary activity TBL, and workload ratios areread and counted up for each secondary activity ID registered in thisTBL. For instance, when the aggregated workload ratio value is 90%, itmeans that less work than (only 90% of) the work done under the standardactivity distribution has been accomplished.

In a set of standard activity IDs, the aggregated workload ratio valueis 100%. The converted quantity-based cost is therefore obtained bydividing the post-environmental variable influence rate eliminationquantity-based cost by (aggregated workload ratio value/100).

Next, the actual performance value of the productivity of the project isconverted into the actual performance value of the cost index standard.This processing is the reverse of the procedure of converting empiricalvalues of the cost index standard productivity into productivitiesapplied to the development of individual software products. The reverseprocessing includes reading and counting up specified request workloadadjustment coefficients which are stored in the activity-by-activityworkload adjustment TBL, reading a specified request scale adjustmentcoefficient out of the scale adjustment coefficient TBL, dividing theconverted quantity-based cost by (specified request scale adjustmentcoefficient×Σ specified request workload adjustment coefficient) toobtain a cost index standard asset-basis cost, which is stored as astandard asset-basis cost in the cost index standard TBL.

Next, the aggregated ultimately realized scale value which has alreadybeen calculated is divided by the specified request scale adjustmentcoefficient to obtain a cost index standard asset amount. The cost indexstandard asset amount is stored as a standard asset amount in the costindex standard TBL.

Developing a software product by remodeling an existing software productinvolves work that is not necessary when developing a software productfrom the scratch, such as studying the existing software product andmaking the result of the remodeling reflected on the specification ofthe existing software product. This embodiment therefore chooses todiscriminate a document of the software product to be studied from adocument of the existing software as a different product. Accordingly,compared with the case of development of an entirely new softwareproduct, there are significantly more types of product.

The cost index standard makes it easy to determine characteristics ofindividual software products by setting a conversion standard table forproducts that are created in development of an entirely new softwareproduct. Products unique to remodeling development are thereforeconsolidated to one of products that are created in development of acompletely new software product. In this embodiment, information thatindicates to which existing product a product unique to remodelingdevelopment is consolidated is held in a consolidation destinationproduct association TBL in advance.

In this table, a product ID that does not match any consolidationdestination product ID is one that needs to be consolidated, and thestandard per-asset cost of this product ID is consolidated to thestandard per-asset cost of a consolidation destination product ID. Theconsolidation is accomplished by: multiplying the standard per-assetcost of the product ID where an increase/decrease in cost due toself-effort has been canceled out by the standard asset amount of theproduct ID, to thereby calculate a cost; dividing this cost by thestandard per-asset cost of the consolidation destination product IDwhere an increase/decrease in cost due to self-effort has been canceledout, to thereby convert the cost into an asset scale corresponding tothe consolidation destination product ID; and storing the scale as aconverted standard asset amount in the cost index standard TBL.

Also, a cost calculated by multiplying the standard asset amount of theproduct ID by the standard per-asset cost of the product ID is dividedby the scale of the asset corresponding to the consolidation destinationproduct ID, to thereby obtain a standard per-asset cost corresponding tothe consolidation destination product ID. The calculated standardper-asset cost is stored as a converted standard per-asset cost in thecost index standard TBL. In the consolidation destination productassociation TBL, a product ID that matches a consolidation destinationproduct ID does not need the conversion. Accordingly, the standard assetamount and the standard per-asset cost in the cost index standard TBLare posted to the converted standard asset amount and the convertedstandard per-asset cost, respectively.

Next, the converted standard asset amount in the cost index standard TBLand a cost that is calculated by multiplying the converted standardasset amount by the converted standard per-asset cost are counted up foreach consolidation destination product ID set in the consolidationdestination product TBL. The aggregated converted standard asset amountis stored as a standard asset amount in the consolidated cost indexstandard TBL. A value that is obtained by dividing the aggregated costof the consolidation destination product ID by the aggregated convertedstandard asset amount is stored as a standard per-asset cost in theconsolidated cost index standard TBL.

Through the above processing, the value of the cost index standard iscalculated for each consolidation destination product ID. The productcost index compiling processing is performed next to unify the actualperformance of the respective products as the actual developmentperformance of a representative product.

First, a scale conversion rate and a cost component ratio are read outof the development unit cost index standard TBL created in the planbasic information definition. The standard asset amount is read out ofthe consolidated cost index standard TBL, and multiplied by the scaleconversion rate to obtain a software product unit amount estimationvalue as an estimation value of the scale of the representative productwhich is associated with the scale of the product ID in question. Next,in order to calculate the contributory share of this product in thefinal software product, the production scale is obtained by multiplyingthe software product unit amount estimation value by the cost componentratio. Next, a cost is read by multiplying the standard asset amount inthe consolidated cost index standard TBL by the standard per-asset cost.The read cost is divided by the cost component ratio to obtain anoverall software product cost estimation value, which is divided by thesoftware product unit amount estimation value to calculate a cost persoftware product unit amount. Every piece of information has now beenconverted into the cost index standard of the representative product,and this is consolidated into information for each combination of asystem ID, a development unit ID, and a project ID. The result is storedas a cost index and a production scale in the project-by-project costindex standard TBL.

(b) Description of “Plan Reference Value Update Processing” (see FIG. 3and FIG. 11)

In this embodiment, actual performance information consolidated uponcompletion of a phase, actual performance information consolidated uponcompletion of a project, and actual cost index performance informationare stored in the management database 3 as a result of theproject-by-project consolidation processing, the developmentunit-by-development unit consolidation processing, and the actualproduction performance consolidation processing.

Generally speaking, individual projects have varying characteristics,and updating the plan reference value requires to go through a procedureof first grouping together projects that have the same characteristic tostatistically analyze the actual performance values of the projects, andthen consolidating the values to a superordinate concept thereof. Theprocedure in this embodiment puts the actual performance of projectsthrough consolidation into client domain-by-client domain actualperformance values for analysis, then consolidation intodomain-by-domain actual performance values for analysis, and lastlyconsolidation into company-wide uniform actual performance values foranalysis.

Domains are for categorizing the characteristics of individual projects.The characteristic of each domain is identified by an analysis keycategory ID and an actual performance analysis key ID. These IDs areheld in advance in an analysis key category TBL and an actualperformance analysis key category TBL.

In each project, an analysis key category ID and an actual performanceanalysis key category ID are set in association with an integration unitID, and each project holds a client code in a project TBL. A user cantherefore have spreadsheet software or a statistical analysis tool togather the actual performance of multiple projects that share the sameclient, the same analysis key category ID, and the same actualperformance analysis key category ID, and read the actual performancevalues of the individual projects to perform various analyses includingregression analysis. The extraction of information to be analyzed mayutilize the index value reference described in the actual productionperformance consolidation processing. Based on the results of theseanalyses, the user updates productivities in the production productivityreference value TBL, which is kept in the management database, and thusupdates the plan reference value.

1. A software development production management system comprising: amanagement database which holds development process component datanecessary to model a development process of software, and estimationparameter data used to estimate a development plan of the software; anda software development production management device which defines asoftware development process to be managed by consulting the developmentprocess component data held in the management database, and uses theestimation parameter data to create a software development plan from thedefined software development process, wherein the software developmentproduction management device has a processing means which, uponcompletion of the software development, compares and evaluates anactually performed development process and the created softwaredevelopment plan, and makes a correction to the estimation parameterdata based on results of the comparison and evaluation so that detailsof the actually conducted software development can be fed back to adevelopment plan for the next time software is developed, wherein thesoftware development production management device includes: a standardplan integration module which defines the software development processto be managed based on the development process component data, and thencreates a standard software development plan containing scales andman-hours of respective work operations in the defined softwaredevelopment process; an execution plan creating module which assigns thework operations to workers taking into consideration the scales andman-hours of the respective work operations in the standard softwaredevelopment plan, and corrects details of the work operations assignedin accordance with abilities of the respective workers to create anadjusted software development plan; an actual performance informationcollecting module which, in developing software in accordance with theadjusted software development plan, collects actual performanceinformation containing actual man-hour performance and actual scaleperformance, the actual man-hour performance being a man-hour that isactually put in by the respective workers, the actual scale performancebeing a scale of work that is actually done; a process completionmonitoring module which, upon completion of the software development,evaluates a difference between details of the actually conducteddevelopment and the software development plan created in the executionplan creating module in a manner that includes a cause of the differenceand quality of the developed software in the evaluation, and feedsresults of the evaluation back to an adjustment made by the executionplan creating module; and an individual productivity evaluating modulewhich evaluates information about productivities of the respectiveworkers taking into consideration the actual man-hour performance andthe actual scale performance, and feeds results of the evaluation backto an adjustment made by the execution plan creating module, wherein themanagement database holds, as a productivity empirical value, a laborcost per unit amount of a product, and records a unit labor cost of eachemployee, and wherein the execution plan creating module calculatesproductivity of each employee by dividing a product of the productivityempirical value and an actual product amount by the unit labor cost ofeach employee.
 2. (canceled)
 3. A software development productionmanagement system as claimed in claim 1, wherein the softwaredevelopment production management device includes an actual productionperformance evaluating module which performs comparative evaluationbetween software development plan forming and work according to theformed plan on multiple software development projects to takestatistics, and feeds the statistics back to the creation of thestandard software development plan in the standard plan integrationmodule.
 4. (canceled)
 5. A software development production managementsystem as claimed in claim 3, wherein the management database has givendevelopment productivity reference data which is a ratio of a givenworkload to given product amount, the given workload being a workload ina given software development environment, the given product amount beinga product amount in the given software development environment, andwherein the execution plan creating module uses a first comparisoncoefficient and a second comparison coefficient as tailoring parameters,and calculates development productivity reference data in softwaredevelopment for which a plan is to be formed by an expression “givendevelopment productivity reference data×second comparisoncoefficient/first comparison coefficient”, the first comparisoncoefficient being a ratio of a product amount in an environment of thesoftware development for which a plan is to be formed to the givenproduct amount, the second comparison coefficient being a ratio of aworkload in the environment of the software development for which a planis to be formed to the given workload.
 6. A software developmentproduction management system as claimed in claim 5, wherein themanagement database holds a productivity fluctuation rate which takesinto account factors influencing a software development productivity,and wherein the execution plan creating module calculates a developmentproductivity in the software development for which a plan is to beformed from the development productivity reference data and theproductivity fluctuation rate.
 7. A software development productionmanagement system as claimed in claim 6, wherein the execution plancreating module keeps track of each specification change made to asoftware product in terms of a specification change time which is whenthe specification change is thought to occur, a change added scale whichis an amount added due to the specification change, and a changediscarded scale which is an amount discarded due to the specificationchange, and wherein the change added scale is added to an initial scaleand the change discarded scale is subtracted from the initial scale eachtime the specification change time arrives to calculate an ultimatelyrealized scale which is a scale the software product will have uponcompletion, the initial scale being a software product scale that iscreated in the standard plan integration module. 8-11. (canceled)
 12. Acomputer program which, when read and executed by a computer with astorage device, builds in the storage device a management database forholding development process component data necessary to model adevelopment process of software, and estimation parameter data used toestimate a development plan of the software, and which causes thecomputer to operate as a software development production managementdevice, the software development production management device defining asoftware development process to be managed by consulting the developmentprocess component data held in the management database, and using theestimation parameter data to create a software development plan from thedefined software development process, wherein the management databaseholds, as a productivity empirical value, a labor cost per unit amountof a product, and records a unit labor cost of each employee, whereinthe computer program causes the computer: to form a processing meanswhich, upon completion of the software development, compares andevaluates an actually performed development process and the createdsoftware development plan, and makes a correction to the estimationparameter data based on results of the comparison and evaluation so thatthe computer can feed details of the actually conducted softwaredevelopment back to a development plan for the next time software isdeveloped, to define the software development process to be managedbased on the development process component data, and then creates astandard software development plan containing scales and man-hours ofrespective work operations in the defined software development process;to assign the work operations to workers taking into consideration thescales and man-hours of the respective work operations in the standardsoftware development plan, and corrects details of the work operationsassigned in accordance with abilities of the respective workers tocreate an adjusted software development plan; to collect, in developingsoftware in accordance with the adjusted software development plan,actual performance information containing actual man-hour performanceand actual scale performance, the actual man-hour performance being aman-hour that is actually put in by the respective workers, the actualscale performance being a scale of work that is actually done; toevaluate, upon completion of the software development, a differencebetween details of the actually conducted development and the softwaredevelopment plan created in the execution plan creating module in amanner that includes a cause of the difference and quality of thedeveloped software in the evaluation, and feeds results of theevaluation back to an adjustment made by the execution plan creatingmodule; and to evaluate information about productivities of therespective workers taking into consideration the actual man-hourperformance and the actual scale performance, and feeds results of theevaluation back to an adjustment made by the execution plan creatingmodule, to calculate productivity of each employee by dividing a productof the productivity empirical value and an actual product amount by theunit labor cost of each employee.
 13. A computer-readable recordingmedium which records the computer program as claimed in claim 12.